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(57) A system and method for secure and verified 
sharing of resources in a peer-to-peer network environ- 
ment to facilitate efficient use of bandwidth are dis- 
closed. The method for securely sharing resources over 
a peer-to-peer network generally comprises broadcast- 
ing a request by a requesting peer for a resource over 
the peer-to-peer network where the resource is identi- 
fied with a resource version identifier, receiving a re- 



sponse from a responding peer on the peer-to-peer net- 
work indicating that the responding peer has the re- 
quested resource, retrieving the requested resource 
from the responding peer, and verifying the retrieved re- 
source by ensuring the retrieved resource contains the 
version identifier embedded therein. Preferably, the ver- 
ifying also includes verifying a digital signature 'such as 
a 1024-bit VeriSign digital certificate, of the retrieved re- 
source to ensure integrity of the retrieved resource. 
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Description 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001 ] This application claims the priority benefit of U. 
S. Provisional Patent Application No. 60/282,333, enti- 
tled "System and Method for Efficient Use of Bandwidth 
and Resources in a Peer-to- Peer Network Environment" 
and filed April 6, 2001 and U.S. Provisional Patent Ap- 
plication No. 60/298,681, entitled "System and Method 
for Efficient Updating of Virus Protection Software and 
Other Efficient Uses of Bandwidth and Resources in a 
Peer-to-Peer Network Environment" and filed June 15, 
2001, both of which are incorporated herein by refer- 
ence in their entireties. 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0002] The present invention relates generally to a 
system and method for efficient use of bandwidth and 
resources in a peer-to-peer network environment. More 
specifically, a system and method for secure and veri- 
fied sharing of resources in a peer-to-peer network en- 
vironment to facilitate efficient use of bandwidth are dis- 
closed. 

2. Description of Related Art 

[0003] Conventionally, to obtain anti-virus product up- 
dates and/or signature files, computers rely on a pull ap- 
proach in which each client or server computer must re- 
trieve the updated anti-virus file directly from a source 
via the Internet. For a computer network, a network ad- 
ministrator may allow anti-virus signature files to be- 
come out of date because there are simply too many 
clients on the network for effective management. Alter- 
natively, the network administrator may schedule the cli- 
ents to automatically pull the updated anti-virus file from 
the Internet when each client logs onto the computer. 
However, such an approach can result in a bandwidth 
crunch such as in the early morning work hours when 
most users log onto their computers. 
[0004] Connections to the internet from within an or- 
ganization, particularly from a small to medium sized or- 
ganization, may be relatively slow. For example, a small 
to medium sized business may share a single cable or 
DSL modem, a 56K modem, oran ISDN line. In contrast, 
in a typical work group interconnected via a LAN, con- 
nections on the LAN are generally much faster, the typ- 
ical LAN being 100/TX (100 Mbps). Peer-to-peer net- 
works thus partially address the need for efficient use of 
bandwidth and resources in a computer network. 
[0005] However, conventionally, peer-to-peer distri- 
bution is not secure and is particularly susceptible to at- 
tacks since a desired resource or a file on the network 
may be compromised as a file distributor does not have 



control of the peer servers that are passing around cop- 
ies of the file on the network. This is of particular concern 
for files that are actual executable binaries and/or for 
files containing potentially critical data such as anti-virus 
5 product updates and signature files. Furthermore, for 
product updates such as anti-virus product updates, a 
requesting peer may not be able to determine whether 
the product files on other peer computers are up-to-date 
or outdated. 

10 [0006] Thus, it is desirable to provide a system and 
method for secure and verified sharing of resources in 
a peer-to-peer network environmentto facilitate efficient 
use of bandwidth to ensure that the shared file has not 
been compromised and/or is up-to-date. Such secure 

'5 and verified sharing of resources over a peer-to-peer 
network ideally expands network resource sharing into 
broader applications such as enterprise software man- 
agement and services. 

20 SUMMARY OF THE INVENTION 

[0007] A system and method for secure and verified 
sharing of resources in a peer-to-peer network environ- 
ment to facilitate efficient use of bandwidth are dis- 

25 closed. The peering service system and method facili- 
tate in spreading load amongst peers in a distributed 
network interconnected via a LAN in a smooth, secure 
and scalable way. The peering service provides security 
mechanisms to ensure that the shared file has not been 

30 compromised and/or is up-to-date. Preferably, the serv- 
ice-enabled application, such as an updating applica- 
tion, implements digital signature security to verify the 
integrity of the retrieved data in order to ensure that the 
resource, such as an update, has not been compro- 

35 mised. The service-enabled application preferably also 
implements version information security measure to en- 
sure that the resource is an up-to-date or otherwise cor- 
rect version. 

[0008] It should be appreciated that the present inven- 
*o tion can be implemented in numerous ways, including 
as a process, an apparatus, a system, a device, a meth- 
od, or a computer readable medium such as a computer 
readable storage medium or a computer network where- 
in program instructions are sent over optical or electron- 
's j c communication lines. Several inventive embodiments 
of the present invention are described below. 
[0009] According to a preferred embodiment, a meth- 
od for securely sharing resources over a peer-to-peer 
network generally comprises broadcasting a request by 
>0 a requesting peer for a resource over the peer-to-peer 
network where the resource is identified with a resource 
version identifier, receiving a response from a respond- 
ing peer on the peer-to-peer network indicating that the 
responding peer has the requested resource, retrieving 
>5 the requested resource from the responding peer, and 
verifying the retrieved resource by ensuring the re- 
trieved resource contains the version identifier embed- 
ded therein. Preferably, the verifying also includes ver- 



2 



BNSDOCID: <EP 1246438A2 I > 



3 



EP 1 248 438 A2 



4 



ify ing a digital signature, such as a 1 024-bit VeriSign dig- 
ital certificate, of the retrieved resource to ensure integ- 
rity of the retrieved resource. 

[0010] The method may further include retrieving a 
catalog containing a listing of resources, comparing the 
resource listing with resources installed at the request- 
ing peer to determine which resources are to be request- 
ed over the peer-to-peer network, and requesting each 
such resource in a separate transaction such that each 
such resource may be retrieved from a same or different 
responding peer. 

[001 1] According to another preferred embodiment, a 
product updating service for automatic and secure up- 
dating of a product installed at a node of a peer-to-peer 
network generally comprises automatically download- 
ing a catalog containing a current listing of resources for 
the product at a predetermined time, comparing the list- 
ing with resources installed at the node to determine 
which resources are to be requested, requesting each 
such resource in a separate transaction over the peer- 
to-peer network, retrieving each resource from a peer 
in the peer-to-peer network or the internet, and verifying 
each retrieved resource by ensuring the retrieved re- 
source contains a version identifier embedded therein. 
[0012] According to yet another preferred embodi- 
ment, a method for providing secure updating of a soft- 
ware product generally comprises providing for retrieval 
over the Internet a catalog containing a current listing of 
resources for the product and providing for retrieval over 
the Intemetthe resources for the product, each resource 
being identified with a resource version identifier and 
contains the resource version identifier embedded 
therein and/or contains a digital signatures such as a 
1 024-bit VeriSign digital certificate. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] Preferred features of the present invention will 
now be described, by way of example only, with refer- 
ence to the accompanying drawings, in which like refer- 
ence numerals designate like structural elements, and 
in which: 

FIG. 1 is a block diagram of an exemplary computer 
network suitable for implementing a peering service 
in a peer-to-peer network to facilitate efficient use 
of bandwidth and resources; 
FIG. 2 is a block diagram illustrating an exemplary 
peering service system and method implemented 
at a node of the computer network of FIG. 1 ; 
FIG. 3 is a state diagram illustrating states of a typ- 
ical peering service server in processing a request 
from a peering client in the peer-to-peer network; 
FIGS. 4A and 4B are alternative state diagrams il- 
lustrating states of a typical peering service client 
in requesting a resource over the peer-to-peer net- 
work; 

FIG. 5 is a flowchart illustrating a typical process of 
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a peering service server in processing a request 
from a peering client in the peer-to-peer network; 
FIG. 6 is a flowchart illustrating a typical process of 
a peering service client in requesting a resource 
over the peer-to-peer network; 
FIG. 7 is a flowchart illustrating a preferred embod- 
iment of the retrieve step of FIG. 6 in more detail; 
FIG. 8 is a flowchart illustrating an exemplary se- 
cure product updating process implemented by a 
service-enabled product updating application over 
a peer-to-peer network; 

FIG. 9 illustrates an example of a computer system 
that can be utilized with the various embodiments 
of method and processing described herein; and 
FIG. 10 illustrates a system block diagram of the 
computer system of FIG. 9. 

DESCRIPTION OF SPECIFIC EMBODIMENTS 



20 [0014] A system and method for secure and verified 
sharing of resources in a peer-to-peer network environ- 
ment to facilitate efficient use of bandwidth are dis- 
closed. The peering service facilitates in spreading load 
amongst peers in a distributed network interconnected 
25 via a LAN in a smooth, secure and scalable way. A serv- 
ice or an application that is service-enabled may mini- 
mize or reduce the usage of, for example, I ntemet band- 
width by attempting to locate a local aliased copy of a 
requested resource residing within the peer-to-peer net- 
so work. If a local aliased copy of the requested resource 
is located, the requesting computer may obtain the re- 
quested resources locally. Once the requesting compu- 
ter obtains a copy of the requested resource, whether 
locally or remotely, the requesting computer may itself 
35 become a server for the aliased copy for subsequent 
requests for the resource. 

[0015] The following description Is presented to ena- 
ble any person skilled in the art to make and use the 
invention. Descriptions of specific embodiments and ap- 
40 plications are provided only as examples and various 
modifications will be readily apparent to those skilled in 
the art. The general principles defined herein may be 
applied to other embodiments and applications without 
departing from the spirit and scope of the invention. 
*s Thus, the present invention is to be accorded the widest 
scope encompassing numerous alternatives, modifica- 
tions and equivalents consistent with the principles and 
features disclosed herein. For purpose of clarity, details 
relating to technical material that is known in the tech- 
no nical fields related to the invention have not been de- 
scribed in detail so as not to unnecessarily obscure the 
present invention. 

[0016] FIG.1 is a block diagram of an exemplary com- 
puter network 1 00 suitable for implementing the peering 
55 service in a peer-to-peer network to facilitate efficient 
use of bandwidth and resources as described herein. In 
particular, the computer network 1 00 comprises nodes, 
computers, or workstations 104A-E interconnected via 
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a LAN 1 02. It is to be understood that the LAN 1 02 may 
be implemented using any suitable network mechanism 
including wire and wireless. In the exemplary computer 
network 100, only two of the nodes 104D and 104E have 
access to the Internet. 

[001 7] FIG. 2 is a block diagram illustrating an exem- 
plary peering service system and method implemented 
at a node of the computer network of FIG. 1 . As shown, 
each node 1 04 provides the functionality of both a server 
1 06 and a client 110. The peering service system utilizes 
a port, such as port 1967, for transmitting directed or 
broadcast messages to peers on the network. The serv- 
er preferably includes an embedded HTTP server 108, 
typically a micro HTTP server. The HTTP server 108 al- 
lows aliased URLs to be accessed by other peers on the 
network. The HTTP server 1 08 preferably uses an ob- 
scure port such as port 651 5 and is preferably restricted 
to operations required to facilitate distribution of , for ex- 
ample, cached files and uploading of data or requests. 
[0018] Typically, each node runs both the server and 
the client. However, each node may run only the client 
or the server. The peering system and method are pref- 
erably implemented as a peering service application 
("service" or "service-enabled application") or daemon 
process. It is noted that a service-enabled application 
need not be a service application. For example, a serv- 
ice-enabled application may also refer to a service- 
aware application that fires up, communicates with the 
service and then shuts down interactively. 
[0019] The peering system preferably provides a link- 
able client API library 112 to facilitate communication 
between the peering service and any service-enabled 
applications. In one preferred embodiment, the peering 
system may export the client AP I library 1 1 2 to any serv- 
ice-enabled application such that the service-enabled 
application may utilize the peering service to discover 
any type of resource that can be identified with a URL 
or URI, for example. Alternatively, a given application 
and the peering service may be tightly coupled so as to 
eliminate the need for the linkable client API library. 
[0020] FIG. 3 Is a state diagram illustrating states 1 20 
of a typical peering service server in processing a given 
request from a peering client in the peer-to-peer net- 
work. Initially, the service server is in an idle state 122 
while listening on a designated port for a broadcast re- 
quest message from a peer client on the network. When 
the service server receives a broadcast request mes- 
sage such as an "I need" packet from a peering client 
on the network, the service server transitions to a locat- 
ing local aliased copy state 124. In particular, the service 
server refers to its list of local aliased copies to deter- 
mine if the service server has a local copy of the request- 
ed resource or item identified by for example, an URL/ 
URI. If the service server determines that it does not 
have a local copy of the requested resource, then the 
service server returns to the server idle state 122. 
[0021] Alternatively, if the service server determines 
that it has a local copy, the service server preferably 



waits a randomly generated delay response time period 
at stage 126. The service server may generate a ran- 
dom number, such as between 0 and 2000, which the 
service server utilizes as the length of time it waits be- 

5 fore responding. In one preferred embodiment, the ran- 
dom number is the number of milliseconds the service 
server waits before replying to the request. While the 
service server awaits expiry of the randomly generated 
delay response time period, the service server listens 

10 for a broadcast "I found" packet from the requesting cli- 
ent corresponding to the received request packet. It is 
noted that regardless of the state of the service server 
for a given peer request, the service server listens for 
new requests such as "I need" packets. The broadcast 

15 "| found" packet from the requesting client indicates that 
the requesting client has found the requested resource. 
If the service server receives an "I found" packet from 
the requesting client before expiry of the delay response 
time period, the service server transitions to state 128 

20 to cancel the response to the request and returns to 
server idle state 122. 

[0022] Alternatively, if no "I found" packet is received 
prior to the expiration of the delay response time period, 
the service server transitions to state 1 30 to transmit an 

25 "| have" packet directly to the requesting peer client. The 
"I have" packet preferably contains a local alias for the 
requested object on the service server which the re- 
questing peer can access via the HTTP server of the of 
the service server. Although not preferred, the service 

30 server may alternatively broadcast the "I have" packet 
over the network rather than transmitting it directly to 
the requesting client. The service server then returns to 
the server idle state 122. 

[0023] As is evident, the randomly generated delay 

35 response time period allows multiple peer servers to 
share loads in an orderly fashion. In particular, rand- 
omizing the delay response time period ensures that 
any given node would not automatically become the de- 
fault serverto a large portion of the peers and eliminates 

40 any need for the service server to exercise preferences 
as to which service clients the service server will supply 
the requested item. In other words, the random wait time 
before responding to a request ensures that any one 
machine does not become an overloaded server of the 

^5 item or update to the rest of the network. In addition, as 
a given item is propagated through the network to peers 
on the network, the load on any one node is likely further 
reduced. Thus, the system impact on a given service 
server as it supplies the requested item to service clients 

50 can be relatively minimal. 

[0024] However, it is to be understood that a situation 
in which multiple service servers each transmitting an "I 
have" packet in response to a given request packet may 
occur. For example, a first service server may transmit 

55 an "I have" packet upon expiry of its delay response time 
period. The "I found" packet transmitted or to be trans- 
mitted by the requesting peer corresponding to the first 
"I have" packet may not arrive at the second service 
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server prior to the expiry of its delay response time pe- 
riod, causing the second service server to transmit an " I 
have" upon expiry of its delay response time period. In 
such a situation where the requesting client receives 
multiple "I have" packets from multiple service servers, 
the requesting client may simply process the first "I 
have" response and ignore any subsequent "I have" 
packets it may receive. 

[0025] FIGS. 4A and 4B are alternative state dia- 
grams illustrating states 140, 140A of a typical peering 
service client in making a given request for a resource 
over the peer-to-peer network. Referring to FIG, 4A, in- 
itially, the service client is in an idle state 142. When a 
service client needs a desired resource, such as an in- 
ternet resource, the service client generates and broad- 
casts an "I need" packet over the peer-to-peer network. 
For example, the "I need" request may specify an URL 
(e.g., http://something.tld/someother/thing/here), a pro- 
tocol (e.g., HTTP protocol), a desired operation (e.g., 
get operation), and that the requesting peer only wants 
cached objects. 

[0026] After broadcasting the "I need" request, the 
service client transitions to a waiting for response state 
144 in which the service client awaits a maximum delay 
response time period plus a transmission time period for 
a response from any of the service servers. In the ex- 
ample above where the randomly generated delay re- 
sponse time period ranges between 0 and 2000 milli- 
seconds, the client response waiting time period would 
be, for example, 2200 milliseconds to allow for a 200 
millisecond transmission time period. 
[0027] If an "I have" response is received from a serv- 
ice server during the client response waiting time, then 
the service client transitions to state 146 and generates 
and broadcasts an "I found" message over the network 
to inform all other peers that the desired resource or item 
has been found. The service client then transitions to 
the requested item found state 158. The service-ena- 
bled application requesting the item then retrieves the 
requested item from the responding service server at 
the location within the network as specified in the re- 
ceived "I have" packet. Generally, the service-enabled 
application retrieves the requested item through the lo- 
cal HTTP server using, for example, port 6515. Once 
the service-enabled application successfully retrieves 
the requested item, the service client informs the service 
server running on the same machine that a local copy 
of the resource now exists. The service client then re- 
turns to the idle state 142. 

[0028] Alternatively, if no response is received during 
the client response waiting time, the service client times 
out and transitions to state 1 50 to retrieve the requested 
item itself such as via the Internet. Once the retrieval is 
complete, the service client transitions to found item 
state 158 in which the service client informs the service 
server running on the same computer or at the same 
node that a local copy of the resource now exists. The 
service client then returns to client idle state 142. As is 



evident, regardless of whether the service client re- 
ceived an "I have" packet from a service server on the 
network, the client machine can itself become a service 
server for the requested resource after successful com- 

5 pletion of its request. 

[0029] FIG. 4B illustrates the 1 40A states of a typical 
service in a preferred alternative embodiment particu- 
larly suitable for applications that include downloading 
of files. States 140A includes the states as shown and 

10 described with reference to FIG. 4A plus additional 
states for dealing with currently in-progress downloads 
of the requested item by other peers. These additional 
states allow a peer node to complete downloading the 
requested resource and then distribute it immediately 

is and automatically upon download completion to the re- 
questing service client. 

[0030] In particular, instead of directly transitioning to 
state 150 to retrieve the requested item itself after the 
service client times out the request, the service client 
transitions to "wait for download?" state 1 44 in which the 
service client determines whether it can or will wait for 
completion of any in-progress download of the request- 
ed item by another peer. If not, then the service client 
transitions to state 150 to retrieve the requested item 
?5 itself and continues with state transitions similar to that 
described above with reference to FIG. 4A. 
[0031] If the service client determines that it can or 
will wait for the completion of any in-progress download, 
the service client transitions to "any in-progress down- 
JO loads?" state 152. If there are no such in-progress 
downloads of the requested item, then the service client 
transitions to state 1 50 to retrieve the requested item 
itself and continues with state transitions similar to that 
described above with reference to FIG. 4A. 
« [0032] Alternatively, if there is at least one in-progress 
download of the requested item, then the service client 
transitions to state 1 54 in which it generates and broad- 
casts an "I found" message. The service client then tran- 
sitions to state 156 to await completion of the in- 
o progress download of the requested item. Upon com- 
pletion of the in-progress download of the requested 
item, the service client transitions to the requested item 
found state 1 58. The service client retrieves the request- 
ed item from the local location within the network. After 
5 successful completion of its request, the service client 
will inform the service server running on the same ma- 
chine that a local copy of the resource now exists. The 
service client then returns to the idle state 142. 
[0033] As is evident, in order for the service client to 
o determine if there are any in-progress downloads in 
state 152, a service client that is downloading a file for 
a service-enabled application preferably broadcasts a 
"downloading" message and/or directly responds to the 
client server of a broadcast "I need" request with a "I am 
* downloading" rather than an "I have" response mes- 
sage. In one preferred embodiment, the service client 
may set a downloading flag for the corresponding file to 
true. 
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[0034] In addition, the service-enabled application 
preferably tmosmits periodic progress packets to any 
node that is waiting for the resource being downloaded 
such that those nodes may intera^iv^ display down- 
load progress information to end users at state 156. Al- 
ternatively/the service-enabled application may broad- 
cast such periodic download progress packets over the 
network. Thus, a node in the retrieve item state 1 50 pref- 
erably periodically transmits a "downloading" message 
that includes progress information. 

Service Functionality and Service Packet Format 

[0035] One functionality provided by the peering serv- 
ice is that of a central clearing house for formatting, 
sending, receiving and decoding service packets, such 
as for "I need," "I found," and "I have" packets. In other 
words, the -$m^rm mmce m&mgm pmr i^pmr 
^mrimmk^m prm^m fm ohmnm<$ rm^smd \tmm. 
Tm 0pmm tvmtemtity invoked by & §*v$n s&*vk?e 
ps«&#* itmtt Is. dependent m W«pee$c serv- 

imM} The cojmiunk^tjon protocol rr> broad- 
casts (e.g., "I need" am *i found" p^ets) and rsspcm- 
es (e.g., "I have" packets) is typically TCP/IP. Each 
packet is typically approximately 200 bytes in size and 
contains the node ID of the sender as well as any other 
suitable information. Transfer of the requested item fmm 
the service server to the service client is typically via 
HTTP. 

[0037] The service packet format is preferably based 
upon the well-accepted and widely utilized XML format. 

For exarnp^ an XM t pmkm tt>fmm may mcJ^de 

a $&rv&& &&nt$k&&&?) ^ndi v$n&u$ 3fc^y-yato--p&i?s< i?>- 
ciudtog sm^© fossae % ^ s^rvto W well as moss 
defined by the corresponding service-enabled applica- 
tion, 

PS38| Vmom fe&y-v$k*a palm rosy b& ^^»'^me 
p^sriog ^ce » ^ sa?vics pacfcat &aampte$ of 
auitafcte J^vafca pates irvstfuda kffc*n$eatfc« s t$p&, am* 

os>?m«pon<ijn9 to lh» Hsquasi to ^jsmi, tm kMmi^ 
tion mhm is unique th& ori^a^ng noda but not 
be unique on the network asawk4 The range of val- 
ues for the identification value may depend upon the 
number of bits assigned thereto. For example, 32 bits 
orfour octets may be assigned to the identification value 
and thus the identification value would range from 0 to 
2 31 . With respect to the type key-value pair, the $$&vah 
ue is typically either request, end-request, response, 
and/or any application-defined value. Any other suitable 
application-defined key-value pairs may also be in- 
cludes in the service packet. 
[0039] An exemplary service packet may be: 

<service type = "request" version = "1.0" ID = 
"1111 8 method = "get" href = "http:/domain.corrvwhatev- 
er" acceptprotocol = "http7> 



[0040] FIG. 5 is a flowchart illustrating a typical proc- 
ess 180 of a peering service server in processing a re- 
quest from a peering client in the peer-to-peer network. 
At step 182, the service server is listening on a desig- 
5 nated port for a broadcast request messa^s from a peer 
client on the network. At step 184, the service server 
receives a broadcast request message on the designat- 
ed port such as an "I need" packet from a peering client 
on the network. At step 186, the service server deter- 
10 mines if it has a local aliased copy of the requested item . 
In particular, the service server refers to its list of local 
aliased copies to determine if the service server has a 
local version of the requested resource or item, such as 
an URL/URI. 

15 [0041] If the service server determines that it does not 
have a local copy of the requested resource, then the 
process 180 is complete. Alternatively, if the service 
$&n^r d«$sra>?nes that it has a loesf sopy, ih® s&m&® 
p?e$qmbfy\i*m& $ mndsmSy generated d^ay m- 

20 spmm tmm period wh&s miming for a broadest "I 
foun<f pac^«i fmm the r«K|««$^g client cafraBjswfwfcng- 
to ma r«««wsd requss* f>sfckfct as step 1 88. As d^usa^ 
th<3 mrvjae server may generate a random 
number between 0 and 2000 as the length of time in 

25 milliseconds it waits before responding. The broadcast 
"I found" packet from the requesting client indicates that 
the requesting client has found the requested resource. 
[0042] It is noted that throughout the process 1 80, the 
service server is preferably continuously listening for 

30 any additional broadcast request messages and per- 
forms process 1 80 for each received broadcast request 
message as they r$c$*ued. 

^ t^ mqu^^ b^to «xp&y ^ tm mt&y 
35 r&*pmmmm p$md> me **rvfe& $&v$r cancels ^a- 
spoift** she r^a^t at step 1 90 and the prccaM 180 
is «^pi^a. A^r^afcvery, if no *J f&untf pacK^Ha 
ssivsd pHor torn* axp^ration ct the de^y response 
p<ma«l tha §srv&& &&v$r iran&roBs an have* packet 
asrsctiy ioths requasafog pm¥<$mx&% step tm mttUm 

^^^^^ ^onta^^ a ta^.&S&aYsnfts- ?s 
on th& mtvk& server. 
|O044J FIG. 6 is a fk?wsfcart illustrating a typical pme- 

45 ess 200 of a peering service client in r^yesting a re- 
source over the peer-to-peer network. At step 202, the 
service client general and broadcasts an "I need- 
packet over me peer-to-peer network on a designated 
port. At step 204, the service awaits for a response from 

50 any of the service servers on the network for a period 
equal to a client response waiting time period/typically 
a maximum delay response time period plus a transmis- 
sion time period, . 

[0045] If an "I fcave" response is received from a serv- 
55 ice server during the client response waiting time, then 
the service client generates and broadcasts an *i found" 
message over the network at step 206. The service-en- 
abled application requesting the item then retrieves the 
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requested item from the responding service server at 
the location within the network as specified in the re- 
ceived "I have" packet at step 208. Once the service- 
enabled application successfully retrieves the request- 
ed item, the service client informs the service server run- 
ning on the same machine that a local copy of the re- 
source now exists at step 210. The process 200 is then 
complete. 

[0046] Alternatively, if no response is received during 
the client response waiting time, i.e., the service client 
times out, the service client determines if the service- 
enabled application can or will wait for completion of any 
in-progress download of the requested item by another 
peer at step 214. If not, the service client retrieves the 
requested item itself such as via the Internet at step 21 6 
and then proceeds to step 21 0 to complete the process 
200. 

[0047] If the service client determines that it can or 
will wait for the completion of any in-progress download, 
the service client determines whether there are any in- 
progress downloads at step 220. If there are no such in- 
progress downloads of the requested item, the service 
client then proceeds to step 21 0 to complete the process 
200. 

[0048] If there is at least one in-progress download of 
the requested item, then the service client generates 
and broadcasts an "I found" message at step 222. The 
service client then awaits completion of the in-progress 
download of the requested item at step 224. For exam- 
ple, the service client may receive an "I have" or a 
"Download complete" message from the downloading 
peer. 

[0049] Upon completion of the in-progress download 
of the requested item, the service client retrieves the re- 
quested item from the local location within the network 
at step 226. After successful completion of its request, 
the service client then proceeds to step 21 0 to complete 
the process 200. It is noted that steps 214 and 220-226 
can be optional and preferably implemented for appli- 
cations that include downloading of files 
[0050] As is evident, in order for the service client to 
determine if there are any in-progress downloads at step 
220, a service client that is downloading a file for a serv- 
ice-enabled application from outside of the network, e. 
g., from the internet, notifies its peers on the network 
that a downloading process is in progress. For example, 
FIG. 7 is a flowchart illustrating a preferred embodiment 
of the retrieve step 21 6 in more detail. 
[0051] As shown, the service client begins retrieving 
the requested item at step 21 6A. At step 21 6B, the serv- 
ice client may broadcast a "downloading" message and/ 
or directly respond with a "I am downloading" response 
message to any client server that transmitted a broad- 
cast "I need" request. In addition, the service client pref- 
erably also periodically transmits progress packets at 
step 21 6C either by broadcast or by direct transmission 
to any node that is waiting for the resource such that 
those nodes may interactively display download 



progress information to end users at those nodes. Alter- 
natively, steps 21 68 and 21 6C may be combined into a 
single periodic packet transmission in which each pack- 
et is a "downloading" message that includes progress 
5 information. 

Service-Enabled Product Updating Application 

[0052] One exemplary implementation of the peering 
10 service described herein is a product updating service 
implementation and a service-enabled application hav- 
ing a shared agent. The agent is shared by an anti-virus 
application and a firewall application. The peering serv- 
ice is encapsulated in a single DLL that contains corn- 
's ponents for performing an update service, namely, a 
peering server having an HTTP server, a peering client, 
and a product updating service. 

[0053] The product updating service determines what 
updates, if any, to request. If the product updating serv- 

20 jce determines that an update is necessary, the service 
client broadcasts an "I need" packet to request a specific 
URL for the necessary product updates. In other words, 
the peering service provides a mechanism for keeping 
service-enabled application, its engine, and its virus sig- 

25 nature files up-to-date. 

[0054] In particular, when a first computer or node 
boots, its product updater broadcasts an "I need" packet 
requesting for my update.cab file at a specified U RL. The 
myupdate.cabfile, e.g., approximately 7-8k in size, con- 

30 tains a script with instructions on how to check the cur- 
rent version of the product, engine, and virus signature 
files against the latest available version so that the prod- 
uct updater can determine if an update is necessary. 
This file may not be cacheable, so the service servers 

35 may not be able to offer it and can instead be obtained 
directly via the Internet. 

[0055] If the product updating service determines, 
based on the myupdate.cab file, that an update is nec- 
essary, the product updating service, via the peering 

40 service, broadcasts an "I need" packet overthe network. 
An update may include engine, DAT, and/or product up- 
dates. For any update files that are downloaded, wheth- 
er directly from the Internet and/or from one or more of 
the peers on the network, the product updating service 

45 preferably checks to ensure that the updates have been 
digitally signed. Once the updates are authenticated, 
they are installed at the requesting node. 
[0056] The product update service checks for updates 
at any suitable pre-defined intervals and/or upon occur- 

50 rence of various events. For example, the product up- 
date service may check for updates upon boot or 5 min- 
utes after boot, 6 hours after each unsuccessful check, 
and/or upon a scheduled basis such as once a day, once 
every 12 hours after each successful check. 

55 [0057] An update can include virus signature files 
(DATs), engine, and/or product update. DATs are typi- 
cally updated weekly, such on a particular day of the 
week and are approximately 900-950k in size on aver- 
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age. The engine is usually updated every 2 to 3 months 
and is approximately 550-600k in size on average. The 
product is updated as hotfixes become available, typi- 
cally every 6-8 weeks, or as new versions become avail- 
able, typically every 4-6 months, and is approximately 
700-750k in size on average. 

[0058] In the current example, a complete update, in- 
cluding engine, virus signature files and product com- 
prises of six *.cab files, totaling approximately 2.25M. 
The six * cab files for an update and their respective av- 
erage sizes are listed below: 



[0059] As any number of these *.cab files may need 
to be updated, each file is preferably requested via the 
peering service in a separate transaction. Thus, some 
or all of the needed *.cab file may be pulied from different 
nodes and/or the Internet. 

[0060] FIG. 8 is a flowchart illustrating an exemplary 
secure product updating process 240 implemented by 
a service-enabled product updating application over a 
peer-to-peer network. At step 242, the service-enabled 
product updating application retrieves a catalog contain- 
ing a listing of files for a current version of the product. 
At step 244, the service-enabled product updating ap- 
plication compares information contained in the catalog 
with versions currently installed at the node to determine 
if an update is needed. If a newer version is available, 
then the service-enabled product updating application 
retrieves the newer version at step 246. Otherwise, the 
process 240 terminates. 

[0061] Preferably, the newer version is located at a 
unique URL that is determined by the specific version 
to enables update to request a specific URL different 
from the URL the application used last time when it in- 
stalled the currently installed version. For example, the 
unique URL may be generated by including an encoding 
of a timestamp in the file name such that a file named 
VsASaP.CAB would named VsASaP. 
2001 01 131 511. CAB if it were released on January 13, 
2001 at 3:11 PM. 

[0062] The unique naming of URLs is desirable be- 
cause the service-enabled product updating application 
attempts to locate local copies of specific URLs. Thus, 
the updating application may not be able differentiate 
between a cached copy of an old VsASaP.CAB file and 
a copy of a most recent version of the VsASaP.CAB file 
without the additional version information encoded into 
the file name. With this unique file name, the updating 
application can ask the service to look for a copy of 
VsASaP.2001 01131511 .CAB on the local network seg- 



ment with assurance that it will obtain the desired file as 
listed in the update catalog. 

[0063] The product updating application preferably 
verifies the integrity of the retrieved data at step 248. 
5 Such integrity verification is highly desirable particularly 
where the retrieved data may be actual executable bi- 
naries. Moreover, with data packets containing poten- 
tially critical data such as anti-virus product updates and 
signature files being passed around in a network, secu- 

10 rity is of great concern. In addition, peer-to-peer distri- 
bution is more susceptible to attacks since the distribu- 
tor of the data files does not have control of the peer 
servers that are passing the files around. Thus, the serv- 
ice-enabled updating application preferably implements 

'5 digital signature and version information security meas- 
ures at step 248 to ensure that the update is not com- 
promised and are versioned properly. 
[0064] In particular, step 248 may include verifying 
that contents of a retrieved data file signed with a digital 

20 signature or certificate have not been altered with use 
of digital signature security measure. Specifically, the 
digital signature is authenticated to verify that the file 
contents have not been altered after it was downloaded 
from the original source, i.e., verify the authenticity of 

25 the file. Any suitable digital signature authentication tool 
such as the 1024-bit Verisign certificate may be utilized. 
[0065] As another desired security measure, step 248 
may additionally or alternatively include a version infor- 
mation security measure to guard against a retrieved 

30 data file that has been renamed from successfully mas- 
querading as the specified file. Because the file name 
is utilized to indicate the version of the file, an old file 
may have been renamed as the requested file. The com- 
promised file may be signed and unaltered and yet its 

35 contents would potentially be outdated or incompatible 
with the current version. Thus, a version information se- 
curity measure is preferred. 

[0066] According to a preferred embodiment, the ver- 
sion information security may be implemented by en- 

40 coding an additional block of data containing version in- 
formation within the digitally signed file such that the ad- 
ditional encoded data can be utilized to verify the file is 
indeed the desired file. In the case of product updating, 
a cabinfo.ini file is optionally added to the MyUpdate. 

*5 cab to specify the original file name for the package. 
Thus, if an older file on the service server was renamed 
to match the current update filename, the embedded file 
description in that file would not match the one included 
in the MyUpdate.cab file on the client and the update file 

50 would be rejected. 

[0067] Finally, at step 250, the product updating ap- 
plication installs the update package at the node. 
[0068] As illustrated in the description above, the 
peering service facilitates in reducing or minimizing the 

55 number of service clients that have to obtain files or oth- 
er resources such as product update files via the Inter- 
net by using secure, peer-to-peer communication to dis- 
tribute the files among client machines on a network, 



Myavdat.YYMMDDHHMM.cab 

Myxtrdat.YYMMDDHHMM.cab 

Mycioagt.YYMMDDHHMM.cab 

Vsasap.YYMMDDHHMM .cab 

Vseng9x.YYMMDDHHMM.cab 

Vsengine.YYMMDDHHMM.cab 



average 910k 
average 16k 
average 370k 
average 360k 
average 240k 
average 340k 
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such as a LAN, via an intranet. The peering service en- 
ables secure, automatic distribution of the update files 
between service clients, independent of a network ad- 
ministrator or end-user, to keep the anti-virus and fire- 
wall application/service up-to-date with minimal impact 
to network bandwidth. 

[0069] Often, many computers on a network do not 
have the most up-to-date anti-virus and/or firewall files. 
Using the secure peering service allows for automatic 
and secure updating of such files and also reduces or 
eliminates the need for a network administrator to script 
anti-virus file updates. Furthermore, by efficiently 
spreading load and utilizing resources across a local 
network over a high-speed LAN, a bandwidth crunch re- 
sulting from the computers pulling update files from the 
Internet is largely reduced. Thus, the peering service al- 
lows for ease of distribution of product upgrades and up- 
dates with a minimal number of computers requiring to 
connect to the Internet to obtain the necessary files re- 
sulting in a reduced usage of Internet bandwidth. 
[0070] The peering service also allows a given client 
to pull the data files from any node on the network, rather 
than having to connect to a centralized server that might 
require several additional network hops, resulting in an 
optimal use of network bandwidth to distribute updates. 
[0071] FIGS. 9 and 10 illustrate a schematic and a 
block diagram, respectively, of an example of a general 
purpose computer system 1000 suitable for executing 
software programs that implement the methods and 
processes described herein. The architecture and con- 
figuration of the computer system 1000 shown and de- 
scribed herein are merely illustrative and other compu- 
ter system architectures and configurations may also be 
utilized. 

[0072] The illustrative computer system 1000 in- 
cludes a display 1003, a screen 1005, a cabinet 1007, 
a keyboard 1 009, and a mouse 1011. The mouse 1011 
can have one or more buttons for interacting with a GUI 
(graphical user interface) that may be displayed on the 
screen 1005. The cabinet 1007 typically house one or 
more drives to read a computer readable storage medi- 
um 1015, system memory 1053, and a hard drive 1055, 
any combination of which can be utilized to store and/ 
or retrieve software programs incorporating computer 
codes that implement the methods and processes de- 
scribed herein and/or data for use with the software pro- 
grams, for example. Examples of computer or program 
code include machine code, as produced, for example, 
by a compiler, or files containing higher level code that 
may be executed using an interpreter. 
[0073] Computer readable media may store program 
code for performing various computer-implemented op- 
erations and may be encompassed as computer stor- 
age products. Although a CD-ROM and a floppy disk 
1015 are shown as exemplary computer readable stor- 
age media readable by a corresponding CD-ROM or 
floppy disk drive 1013, any other combination of com- 
puter readable storage media can be utilized. Computer 



readable medium typically refers to any data storage de- 
vice that can store data readable by a computer system. 
Examples of computer readable storage media include 
tape, flash memory, system memory, and hard drive 
5 may alternatively or additionally be utilized. Computer 
readable storage media may be categorized as magnet- 
ic media such as hard disks, floppy disks, and magnetic 
tape; optical media such as CD-ROM disks; magneto- 
optical media such as floptical disks; and specially con- 
10 figured hardware devices such as application-specific 
integrated circuits (ASICs), programmable logic devices 
(PLDs), and ROM and RAM devices. Further, computer 
readable storage medium may also encompass data 
signals embodied in a carrier wave, such as the data 
15 signals embodied in a carrier wave carried in a network. 
Such a network may be an intranet within a corporate 
or other environment, the Internet, or any network of a 
plurality of coupled computers such that the computer 
readable code may be stored and executed in a distrib- 
20 uted fashion. 

[0074] Computer system 1000 comprises various 
subsystems. The subsystems of the computer system 
1000 may generally include a microprocessor 1051, 
system memory 1053, fixed storage 1055 (such as a 
25 hard drive), removable storage 1057 (such as a 
CD-ROM drive), display adapter 1059, sound card 
1061, transducers 1063 (such as speakers and micro- 
phones), network interface 1065, and/or scanner inter- 
face 1 067. 

30 [0075] The microprocessor subsystem 1051 is also 
referred to as a CPU (central processing unit). The CPU 
1 051 can be implemented by a single^hip processor or 
by multiple processors. The CPU 1051 is a general pur- 
pose digital processor which controls the operation of 
35 the computer system 1 000. Using instructions retrieved 
from memory, the CPU 1 051 controls the reception and 
manipulation of input data as well as the output and dis- 
play of data on output devices. 

[0076] The network interface 1065 allows CPU 1051 
40 to be coupled to another computer, computer network, 
or telecommunications network using a network con- 
nection. The CPU 1051 may receive and/or send infor- 
mation via the network interface 1065. Such information 
may include data objects, program instructions, output 
45 information destined to another network. An interface 
card or similar device and appropriate software imple- 
mented by CPU 1051 can be used to connect the com- 
puter system 1000 to an external network and transfer 
data according to standard protocols. In other words, 
50 methods and processes described herein may be exe- 
cuted solely upon CPU 1051 and/or may be performed 
across a network such as the Internet, intranet net- 
works, or LANs (local area networks), in conjunction 
with a remote CPU that shares a portion of the process- 
55 ing. Additional mass storage devices (not shown) may 
also be connected to CPU 1051 via the network inter- 
face 1065. 

[0077] The subsystems described herein are merely 
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illustrative of the subsystems of a typical computer sys- 
tem and any other suitable combination of subsystems 
maybe implemented and utilized. For example, another 
computer system may also include a cache memory 
and/or additional processors 1051, such as in a multi- 
processor computer system. 

[0078] The computer system 1 000 also includes a 
system bus 1069. However, the specific buses shown 
are merely illustrative of any interconnection scheme 
serving to link the various subsystems. For example, a 
local bus can be utilized to connect the central processor 
to the system memory and display adapter. 
[0079] While the present invention has been de- 
scribed in its preferred embodiments, it is to be under- 
stood that the words which have been used are words 
of description rather than limitation and that changes 
may be made to the invention without departing from its 
scope as defined by the appended claims. 
[0080] Each feature disclosed in this specification 
(which term includes the claims) and/or shown in the 
drawings may be incorporated in the invention inde- 
pendently of other disclosed and/or illustrated features. 



retrieving each resource to be requested from 
one of a peer in the peer-to-peer network and 
the Internet; and 

verifying each retrieved resource by ensuring 
the retrieved resource contains the version 
identifier embedded therein. 

3. The method for securely sharing resources over a 
peer-to-peer network of claim 1 or the product up- 
dating service for automatic and secure updating of 
a product installed at a node of a peer-to-peer net- 
work of claim 2, wherein said verifying the or each 
retrieved resource further comprises verifying a dig- 
ital signature of the or each retrieved resource to 
ensure integrity of the retrieved resource. 

4. The method for securely sharing resources over a 
peer-to-peer network of claim 1 or 3 or the product 
updating service for automatic and secure updating 
of a product installed at a node of a peer-to-peer 
network of claim 2 or 3, further comprising installing 
the or each retrieved resource. 



Claims 



A method for securely sharing resources over a 
peer-to-peer network, comprising: 

broadcasting a request by a requesting peer for 
a resource over the peer-to-peer network 
wherein the request contains an identification 
of the resource and the resource identification 
contains a resource version identifier; 
receiving a response from a responding peer 
on the peer-to-peer network indicating that the 
responding peer has the requested resource; 
retrieving the requested resource from the re- 
sponding peer; and 

verifying the retrieved resource by ensuring the 
retrieved resource contains the version identi- 
fier embedded therein. 

A product updating service for automatic and se- 
cure updating of a product installed at a node of a 
peer-to-peer network, comprising: 

automatically downloading a catalog contain- 
ing a current listing of resources for the product 
at a predetermined time, each resource being 
identified by a resource version identifier; 
comparing the listing of resources in the catalog 
with resources installed at the node to deter- 
mine which resources are to be requested over 
the peer-to-peer network; 
requesting each resource to be requested in a 
separate transaction over the peer-to-peer net- 
work; 



25 



30 
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The method for securely sharing resources over a 
peer-to-peer network of any of claims 1 , 3 or 4, fur- 
ther comprising retrieving a catalog containing a 
listing of resources. 

The method for securely sharing resources over a 
peer-to-peer network of claim 5, further comprising 
comparing the listing of resources with resources 
installed at the requesting peer to determine which 
resources are to be requested over the peer-to-peer 
network. 

The method for securely sharing resources over a 
peer-to-peer network of claim 6, further comprising 
requesting each resource to be requested in a sep- 
arate transaction such that each resource to be re- 
quested may be retrieved from a same or different 
responding peer. 

A method for providing secure updating of a soft- 
ware product, comprising: 

providing for retrieval over the Internet a cata- 
log containing a current listing of resources for 
the product; and 

providing for retrieval over the Internet the re- 
sources for the product, 

wherein each resource is identified with a re- 
source version identifier and contains the resource 
version identifier embedded therein. 

The method for providing secure updating of the 
software product of claim 8, wherein each resource 
is digitally signed with a digital signature. 
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10. A computer program product for securely sharing 
resources over a peer-to-peer network, comprising: 

computer code that broadcasts a request by a 
requesting peer for a resource over the peer- s 
to-peer network wherein the request contains 
an identification of the resource and the re- 
source identification contains a resource ver- 
sion identifier; 

computer code that receives a response from w 
a responding peer on the peer-to-peer network 
indicating that the responding peer has the re- 
quested resource; 

computer code that retrieves the requested re- 
source from the responding peer; is 
computer code that verifies the retrieved re- 
source by ensuring the retrieved resource con- 
tains the version identifier embedded therein; 
and 

a computer readable medium that stores said 20 
computer codes. 

1 1 . The computer program product for securely sharing 
resources over a peer-to-peer network of claim 1 0, 
wherein said computer code that verifies the re- 25 
trieved resource further comprises computer code 
that verifies a digital signature of the retrieved re- 
source to ensure integrity of the retrieved resource. 

12. Thecomputerprogramproductforsecurelysharing 30 
resources over a peer-to-peer network of claim 10 

or 11 , further comprising computer code that installs 
said resource. 



a product installed at a node of a peer-to-peer net- 
work of claim 3 or the method for providing secure 
updating of the software product of claim 9 or the 
computer program product for securely sharing re- 
sources over a peer-to-peer network of claim 11, 
wherein said digital signature is a 1024-bit VeriSign 
digital certificate. 



13. The computer program product for securely sharing 35 
resources over a peer-to-peer network of any one 

of claims 10 to 12, further comprising computer 
code that retrieves a catalog containing a listing of 
resources. 

40 

14. The computer program product for securely sharing 
resources over a peer-to-peer network of claim 13, 
further comprising computer code that compares 
the listing of resources with resources installed at 
the requesting peer to determine which resources 45 
are to be requested over the peer-to-peer network. 

15. The computer program product for securely sharing 
resources over a peer-to-peer network of claim 1 4, 
further comprising computer code that requests so 
each resource to be requested in a separate trans- 
action such that each resource to be requested may 

be retrieved from a same or different responding 
peer. 

55 

16. The method for securely sharing resources over a 
peer-to-peer network of claim 3 or the product up- 
dating service for automatic and secure updating of 
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